KURZUS: Rendszer és irányítás

MODUL: VI. Modul: Számítógép alapú rendszerek fejlesztése

12. lecke Szoftvertervezési módszerek, módszertanok

| A szoftverfolyamat modellek javaslatot adnak a tevékenységek végrehajtási menetére, de nem adnak tiszta megoldást arra, hogyan, milyen eszközök, módszerek segítségével történjen a végrehajtás, milyen módon, milyen szimbólumokkal történjen az eredménytermékek leírása, a fejlesztés dokumentálása.
A szoftverfolyamat modellek ezen hiányosságát oldják meg a szoftverfejlesztési módszertanok, amelyek elsődleges célja egyfajta keret biztosítása a szoftverfejlesztés mérnöki oldalának. A 2. lecke a szoftverfejlesztési módszertanokkal és a modellező nyelvekkel kapcsolatos alapkérdéseket, alapösszefüggéseket foglalja össze, nem célja azoknak a részletes mélységeiben történő bemutatása.
Követelmények: Ön akkor sajátította el megfelelően a tananyagot, ha
meg tudja magyarázni a szoftverfejlesztési módszertanoknak és a modellező nyelveknek a fejlesztésben betöltött szerepét, rendeltetését, látja a módszertanok és a modellező nyelvek közötti különbségeket, fel tud sorolni módszertanokat, modellező nyelveket.
Időszükséglet: A tananyag elsajátításához körülbelül 40 percre lesz szüksége.
Kulcsfogalmak
szoftverfejlesztési módszertan, szoftvertervezési módszerek, modellező nyelv, UML modellező nyelv.
Szoftverfejlesztési módszertan
A módszertanok egy szoftverfolyamat modell (pl. vízesés modell) alapján megadják a fejlesztési tevékenységek végrehajtásának menetét, valamint módszereket, eszközöket javasolnak a tevékenységek végrehajtására. A módszertanok többsége ajánlást ad a fejlesztési tevékenységek eredményeként előálló termékekre, azok tartalmára és formájára.
A módszertanok között vannak olyan módszertanok is, amelyek nem fedik le a teljes fejlesztési folyamatot. Ez esetben a projektvégrehajtás során a projektszereplők dönthetnek úgy, hogy a tevékenységek végrehajtására több módszertant is alkalmaznak.
Tekintsünk át röviden két olyan szoftverfejlesztési módszertant, ahol az egyik lefedi a teljes szoftverfejlesztési életciklust, a másik nem.
Habár napjaink projektjei inkább az innovatív, modern módszertanokat vetik be a szoftverfejlesztés során, nem szabad csak úgy egyszerűen megfeledkezni a korábban előszeretettel alkalmazott SSADM módszertanról. A módszertant előszeretettel alkalmazták nagy volumenű projektek esetén. Ha az SSADM módszertant abból az aspektusból értékeljük, hogy mennyire fedi le a fejlesztési folyamatot, akkor az SSADM egy tipikus példája lehet annak, hogy csak a fejlesztés bizonyos területeire, tipikusan a rendszerelemzés és rendszertervezés végrehajtására ad megoldást. A módszertan nagy hátránya éppen ebből fakad. Nem szolgál egyértelmű válasszal arra, hogy a megtervezett rendszer hogyan fog működni, hogyan fog kommunikálni a környezettel és hogyan történik a rendszerkövetés. Az SSADM által használt módszerek között találjuk az adatfolyam-modellezést, az adatmodellezést, a funkció meghatározást, a dialógustervezést, fizikai adattervezést. A módszertan saját jelölésrendszerrel rendelkezik a szoftvertermék modellek leírására. Sok szoftverfejlesztési projekt dönt a Rational cég által fejlesztett RUP (Rational Unified Process), ma már UP névre keresztelt módszertan mellett. Az UP a szoftverfejlesztés teljes életciklusát lefedi. A módszertan egyedi igényekhez adaptálható eszköztárat biztosít a projektek számára. Az iteratív, inkrementális, komponens alapú megközelítések mellett a módszertan architektúra-centrikus, use case vezérelt. A fejlesztés kerete egy kétdimenziós modell. A módszertan a vízszintes tengely mentén a fejlesztés időbeli végrehajtását 4 fázissal írja le. A fázisok egy vagy több iteráció mentén teljesülnek. Egy iteráció a függőleges tengely mentén definiált munkafolyamotokat az időbeliség függvényében különböző intenzitással (a modellben ezt az egyes munkafolyamatokat szimbolizáló sávos ábra magassága szemlélteti) tartalmazza. Ha az Olvasó most a vízesés modellnek egy elforgatott változatára asszociál, akkor nagyon közel van ahhoz a varázslathoz, ami azt mutatja, hogy egy-egy iteráció nem más, mint egy vízesés modell, aminek a végére a fejlesztendő szoftverrendszer egy adott készültségi fokú verziója áll elő. A függőleges tengely mentén levő dimenzió azt is megmondja, hogy az egyes iterációkban, a munkafolyamatokban milyen fejlesztési termékeket (diagramok, dokumentumok, kód stb.) kell elkészíteni (lásd 1. ábra ).
RUP kétdimenziós modellje
1. ábra
| A RUP a modellezési technikákra épít. A RUP módszertanban definiált modellek írják le a szoftvertermék különböző nézeteit (pl. a use case modell a rendszer funkcionalitását írja le, az elemzési modell a rendszer struktúráját határozza meg). A módszertan sajátossága, hogy nincs saját jelölésrendszere. A fejlesztési termékek leírására a de facto szabványként támogatott UML (Unified Modeling Language - általános célú modellező nyelv) modellező nyelvet használja.
A fent bemutatott két módszertan mellett további módszertanok:
Gane and Sarson, deMarco, Yourdon, Martin féle módszertanok, Chen egyed-kapcsolat modellje, SADT (Ross); DSSD (Warnier-Orr), Yourdon féle OOA/D '90,'94 Jacobson OOSE '94, Objectory Booch OOADA '93 Martin-Odell OOIE '92 Rumbaugh OMT '91 Lorensen '86 stb.
Melyik módszertant válasszuk a probléma megoldására? A választáshoz több szempontot kell értékelni:
A módszertant: az adott feladathoz és fejlesztői csapathoz kell igazítani, testre szabni. A választást erősen befolyásolja a feladat jellege. Így például a vízesés modell jó választás lehet olyan projektek esetén, ahol a követelmények egyértelműek. A módszertanok gyakran nem fedik le a teljes szoftverfolyamat, illetve annak minden vetületét. Ilyen esetben akár több módszertant is lehet alkalmazni, csak arra kell ügyelni, hogy azok kompatibilisek legyenek egymással.
Szoftvertervezési módszerek
A fejlesztési tevékenységek végrehajtását, vagyis azt, hogy szoftverfolyamatban az egyes tevékenységeket hogyan kell/lehet megvalósítani a szoftverfejlesztési módszerek segítik.
A szoftvertervezési módszerek a szoftverfolyamatban a tevékenységek végrehajtására adnak javaslatot. A módszer tárgya és célja szerint tervszerű eljárás, amely az ismeretek és gyakorlati eredmények megszerzésére irányul. A szoftverspecifikáció során a munkát olyan módszerek segíthetik, mint például a SWOT analízis, az interjúk, a kérdőívek, a use case modellezés stb. A tervezés jól bevált módszerei a modellalkotás, az absztrahálás, leképezés, modulokba szervezés. Az implementáció és tesztelés feladatait segítő módszerek a struktúradiagram, az architektúra diagram, a menütervezést segítő megoldások, a tesztelési módszerek (szemantikai, szintaktikai ellenőrzés) stb. A rendszerfelügyelet, üzemeltetés jól bevált módszerei közé tartoznak a minőségmodellek, változásmenedzsment, megbízhatóság (MTBF, MTTR), hatékonyság, integritás, költséghatékonysági számítások, kihasználási mutatók, eseményfelügyelet, verziókezelés, hatékonyság mérés stb.
Szoftvertermék-modell
A fejlesztési termékek (lásd Szoftverfolyamat bekezdés alatt) gyakran szoftvertermék-modellek (pl. osztály diagram, use case diagram, szekvencia diagram) formájában készülnek el.
Szoftvertermék-modell: a szoftverfejlesztés eredménytermékeként létrehozott modell (pl. osztály diagram, use case diagram, szekvencia diagram), mely a leendő szoftvert egy adott aspektusból (pl. felépítés, működés) írja le.
A szoftvertermék-modellek egy adott modellezési nyelv (szimbólumrendszer) használatával készülnek, mely nyelvek saját szintaktikai és szemantikai szabályrendszerrel rendelkeznek.
Modellező nyelv
A szoftverprojektek célja a felhasználói igényeket kielégítő, a felhasználó által könnyen használható szoftverrendszerek fejlesztése. A megvalósításhoz meg kell érteni az igényeket, az igények alapján le kell tudni írni a rendszer működését, a rendszer elemeit, az elemek kapcsolatát. A rendszerek leírásának egyik, a gyakorlatban jól bevált módszere a modellalkotás. Egy rendszer teljes körű feltáráshoz a rendszert több nézőpontból vizsgáljuk. Ezek lesznek a rendszer modellnézetei, ahol az egyes nézetek a rendszert más-más szemszögből írják le, más-más oldalról mutatják pl. a folyamat nézet a rendszer működését, a rendszer statikus nézete az elemeket és a közöttük levő kapcsolatokat stb. ábrázolja. A különböző nézeteket modellek formájában írjuk le. Ezek a modellek gyakran grafikus reprezentációk (pl. diagramok) formájában kerülnek leírásra. Az UML modellező nyelv például öt nézetet javasol:
use case nézet: a rendszer funkcionalitását írja le, definiálja a szerepköröket és funkciókat, logikai nézet: a rendszer belső struktúráját írja le, a rendszer statikus elemeit és struktúráját, valamint az objektumok együttműködésének a formáját írja le, folyamat nézet: a rendszert folyamataira és a végrehajtó elemekre tagoljuk, azonosítjuk a párhuzamosan végezhető műveleteket, komponens nézet: programkomponensek és állományok specifikációja, függőségi viszonyai kerülnek meghatározásra, amelyek leírása komponens diagramokkal történik, telepítési/működési nézet: a rendszer fizikai működésének megvalósítása, a fizikai architektúra, hardver topológia: számítógépegységek (node - csomópontok) és elemek leírása tartozik ebbe a nézetbe.
UML nézetek
2. ábra
A modellek pontos, precíz megadásához azonban nem elég, ha csak diagramokat készítünk. A teljes leíráshoz érdemes egy modellező nyelvet választani, amely tartalmaz:
nyelvi elemeket (szintaktikai szabályok), amelyekhez szöveges (VHDL, Java) vagy grafikus (UML, BPML) jelölésrendszert társít. Több modellező nyelv (pl. az UML modellező nyelv) szöveges és grafikus jelölésrendszert is meghatároz. A szöveges nyelv előnye, hogy könnyebb vele modellt építeni, ellenben a grafikus nyelvek jobban alkalmasak a modellek olvasására, kifejezőbbek, így jelentős segítséggel szolgálnak a különböző szerepkörök (pl. megrendelő és fejlesztő csoport között vagy fejlesztő csoport tagjai között) közötti kommunikációban. egy nyelvi szabályrendszert (szemantikai szabályok), ami a nyelvi elemek jelentését adja pl. név, láthatóság stb.
A modellező nyelvek szerepe:
a modellező nyelvek jellemzően mind a valóság, mind a rendszer belső szerkezetének ábrázolását segítik az üzleti modelltől a telepítési modellig. könnyen áttekinthető és érthető kommunikációs nyelvként szolgálnak a fejlesztő és felhasználó számára egyaránt. független a fejlesztési folyamatoktól és az alkalmazott módszerektől. megkönnyíti és egyszerűsíti a dokumentálást. nemzetközi projektekben az eltérő nyelvhasználatból adódó nehézségeket, félreértelmezéseket megoldja, a fejlesztők az egységes modellező nyelv segítségével kommunikálnak, dokumentálnak.
Az UML modellező nyelv
Sok szoftverfejlesztési projekt dönt az UML nyelv használata mellett. Az UML-t eredetileg a megalkotói abból a célból hozták létre, hogy legyen "egy általános célú vizuális modellező nyelv, amely arra használható, hogy specifikáljuk, szemléltessük, megtervezzük és dokumentáljuk egy szoftver rendszer architektúráját". Az UML diagramjai nem újonnan definiált diagramok voltak. Sok közülük más módszertanokból került átvételre. Az Olvasó jogosan kérdezheti, miért mégis az UML? Az UML-nek azért volt átütő ereje a szoftverfejlesztés területén, mert a szakmai grémium egy jól átgondolt, általános célú modellező nyelvet alkotott, amelyet 1997-ben az objektumorientált rendszerek elterjedését hirdető OMG (Object Management Group) konzorcium szabványként elfogadott.
Az UML általános jelölésrendszere nemcsak szoftvermodellek létrehozását támogatja. A nyelv jól használható az üzleti folyamatok leírására, különböző szerepkörök közötti kapcsolatok ábrázolására, rendszerek, szervezetek működésének modellezésére, adatbázismodellek építésére.
Az UML nem módszertan. A módszertanokkal ellentétben csak egy általános szimbólumrendszert ad, amellyel tervezni és modellezni tudjuk a fejlesztendő szoftverrendszert. Nem határozza meg a fejlesztés végrehajtási menetét, sem azt, hogy a modelleket és diagramokat milyen módon és sorrendben kell elkészíteni. Az UML 2.0 verziója 13 diagramot határozott meg két fő bontásban:
A strukturális diagramok a modellezett rendszer elemeit, a rendszer struktúráját modellezik. A viselkedési diagramok a működést írják le, hogy minek kell történnie a modellezett rendszerben.
Strukturális diagramok | Viselkedési diagramok
osztály diagram komponens diagram összetett struktúra diagram telepítési diagram objektum diagram csomag diagram | aktivitási diagram állapot/állapotgép diagram use case diagram kommunikációs diagram szekvencia diagram interakciós áttekintő diagram időzítő diagram
Use case diagram részlet UML-lel ábrázolva
3. ábra
Az UML-lel szemben számos kritika is napvilágot látott. A nyelvbe sok diagramot definiáltak, melyek redundánsak, ezért azok használata bonyolulttá, nehezen áttekinthetővé teszi a modellek leírását. AZ UML nem mindig egyértelmű szemantikája szintén megnehezíti a modellek értelmezését. Ezeket a problémákat az UML folyamatos továbbfejlesztésével próbálják megoldani.